Skip to content

Plot rendering fix when PV disconnects#2189

Merged
georgweiss merged 1 commit intomasterfrom
CSSTUDIO-1606
Mar 24, 2022
Merged

Plot rendering fix when PV disconnects#2189
georgweiss merged 1 commit intomasterfrom
CSSTUDIO-1606

Conversation

@georgweiss
Copy link
Collaborator

In the Stripchart widget using trace type "step", a horizontal line is painted when the associated PV disconnects. Once it connects the available values will be rendered, but the horizontal line in most cases remains, see screen shot.

This defect is not seen when using trace type "line".

This PR is an attempt to fix the issue so that the behavior for "step" is the same as for "line".

Screenshot 2022-03-21 at 09 04 32

@georgweiss georgweiss requested a review from kasemir March 23, 2022 13:56
@georgweiss georgweiss merged commit 3aeb701 into master Mar 24, 2022
@kasemir kasemir deleted the CSSTUDIO-1606 branch March 29, 2022 17:53
@kasemir
Copy link
Collaborator

kasemir commented Mar 12, 2026

The change in drawValueStaircase from

if (poly_x.size() > 0  && x != last_x)

to

if (poly_x.size() > 0  && x != last_x && !Double.isNaN(value))

causes a problem.

Consider a trace with disconnected data.

Screenshot 2026-03-12 at 9 54 22 AM

The archived samples are considered to be valid until there's a new sample. This includes the disconnected case. The trace, at least in "staircase" mode, should continue from the last known sample to the point of disconnect.
After this change, the trace stops at each sample before the disconnect, resulting in large gaps:

gap

By restoring drawValueStaircase to use just if (poly_x.size() > 0 && x != last_x) as was the case before this change, the trace continues up to the disconnect, resulting in only a brief gap that more correctly represents the value over time:

continued

@georgweiss
Copy link
Collaborator Author

One would assume that Stripchart and Databrowser uses the same plot engine...

@kasemir
Copy link
Collaborator

kasemir commented Mar 12, 2026

Yes. Your original screenshot suggests that the order of samples is somehow getting disturbed. The time stamps must be sorted. The 'fix' on the plotting side just added a new bug.

@georgweiss
Copy link
Collaborator Author

OK, will take a look.

@georgweiss
Copy link
Collaborator Author

Since I cannot reproduce the issue (and neither can the user reporting on it), I have reverted this change.
See #3736

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants